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METHOD AND HS2^S IN A TELECQMMONXCATXON SYSTEM 
TECHNICAXi FIELD OF THE INVENTION 

The present invention relates generally to radio 
communication and cornputer systems, methods, devices and 
5 data packets for general benchmark testing of said systems, 
and specifically to load and stress testing of at least one 
node, such as e.g. a GTP (GPRS Tunnelling Protocol) capable 
node in a GPRS (General Packet Radio Service) and UMTS 
(Universal Mobile Telecommunications Systems) system. 

10 DESCRIPTION OF RELATED ART 

The lETF's (Internet Engineering Task Force) is the IP 
standardisation boc3y which produces standards named Recjuest 
For Comments (RFC). The lETF's RFC 2544 discusses and 
defines a number of tests that may be used to describe the 
15 performance characteristics of a network interconnecting 
device and describes specific formats for reporting the 
results of the tests. 

The focus of RFC 2544, which is a standard of the Intezniet 
Society (1999), is on creating some guidelines in order to 
20 perform tests that product vendors can use to measure and 
report the performance characteristics of network devices. 
The results of these tests aim at providing comparative data 
from different vendors which can be used to evaluate these 
devices . 

25 The GTP (GPRS Tunnelling Protocol) protocol is outside the 
scope of the Internet Society to which the proposal in 
S.Bradner and J. McQuaid. ''Benchmarking Methodology for 
Network Interconnect Devices" (RFC 2544, March 1999) 
belongs. The mentioned proposal is only concerned with 

30 traffic going in and out of only one of the two types of 
interfaces (i.e. only Gi) that a GTP capable node can 
inclement . The proposal can therefore be applied only for 
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testing traffic load going from Gi to Gi and no one of the 
other three combination (Gi to Gn, Gn to Gn, Gn to Gi) of 
the two different types of interfaces. 

The existing proposal cannot be used as a way of testing the 
5 GTP node because it does not take into account a process 
whereby GTP-specific parameters are varied in order to 
perform a full test of the node. 

The interfaces Gn, Gp and Gi have been defined by the 3GPP 
group. The protocol nonning on Gn and Gp interfaces uses the 
10 GTP protocol, which has been introduced by the 3GPP group 
especially for GPRS (General Packet Radio Services) / UMTS 
(Universal Mobile Telecommunications Services) . The GTP 
header encapsulates the IP/UDP or IP/TCP data in order to 
direct data to the user in a correct manner. 

15 The' IP (user) data in the Gn interface is encapsulated with 
a GTP header, which is transported into the network using 
the IP (transport) address of the GTP-capable node (i.e. 
GGSN or SGSN) where it is directed- The particular structure 
of the GTP data (and IP encapsulation) requires a specific 

20 procedure for testing the performance in a GTP capable 
device in order to produce benchmark results. Such a 
specific procedure will therefore be different from that 
described in S.Bradner and J. McQuaid. ''Benchmarking 
Methodology for Network Interconnect Devices" (RFC 2544, 

25 March 1999) for testing IP router devices. In particular the 
existing standard see e.g. in that document did not (and 
could not) consider the additional parameters involved in 
setting up GTP tunnels and test traffic performance 
involving the interfaces Gn and Gi under different 

30 conditions. 

SUUMZmY OF THE INVENTION 

The problem dealt with by the present invention is providing 
a general benchmark testing methology and testing device for 
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load testing or stress testing of at least one network node 
in a radio communication system. 

Briefly, the present invention solves said problem by 
sending at least one data packet to at least one interface 
5 of a network node and analyzing the data packet /s returning 
as a response to said sent data packet/s. 

The problem is solved by method according to claim 10, and 
device according to claims 301 and data packet according to 
claim 303 . 

10 An object of the invention is to provide an enhanced 
testing methology which is simple and fast to use. 

A further object is to provide a standardized performance 
testing methology for a network node. 

Another object of the invention is to benchmark a network 
15 node through load and stress testing it so that it may be 
compared with nodes from different vendors. 

An advantage afforded by the invention is a simple and fast 
testing methology. 

A further advantage afforded by the present invention is a 
20 standardized performance testing methology for a network 
node. 

Another advantage of the present invention is to acquire 
benchmark data from analyzing the test results through load 
and stress testing different vendors nodes. 

25 Other objects, advantages and novel features of the 
invention will become apparent from the following detailed 
description of the invention when considered in conjunction 
with the accompanying drawings and claims. 

DESCRXPTION OF THE DRAWINGS 
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FIG. 1 is a block diagram illustrating a the relevant parts 
of the GPRS / UMTS network with one embodiment of the 
testing device according to the invention. 

FIG. 2 is a schematic representation illustrating a GTP 
5 protocol . 

FIG. 3 is is a block diagram illustrating an embodiment of a 
setup to be used during the tests according to the 
invention. 

FIG. 4 is a schematic representation illustrating the GTP 
10 header format. 

FIG. 5 is a schematic representation illustrating a GTP 
header followed by a Information Elements. 

DESCRIPTION OF PREFERRED EBOBODISSENTS 

According to the invention a general benchmark testing 
15 methodology is offered for load testing or stress testing 
GTP (GPRS Tunneling Protocol) capable nodes such as e.g. the 
GGSN (Gateway GPRS Support Node) , and to evaluate the 
performance of a GTP node by appropriately loading the Gi 
121 and Gn/Gp 120/122 interfaces. In the case of GPRS 
20 (General Packet Radio Services), when the interfaces Gn 120 
and Gi 121 are tested, an appropriate packet generator will 
emulate the downstream node (SGSN 111-113, Serving GPRS 
Support Node) . 
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25 The introduction by the 3GPP group of a new type of 
interface (Gn 120) has the effect of introducing for load 
testing proposal, four combinations of input /output 
interfaces types as depicted in TAB. 1. The combination Gi 
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121 to Gi 121, is typical of a router according to prior art 
and will thereby not be covered here. The aim of the 
invention is to cover the other three input/output interface 
combinations, which characterise specifically a GTP capable 
5 node and make the node different from a pure IP (Internet 
Protocol) router. 

In FIG. 1 a simplified figure illustrating the relevant part 
of the GPRS / UMTS network is shown - 

The introduction from 3GPP of the GTP protocol and its use 
10 in the GPRS networks and all 3G system is expected to be 
very high. The GGSN nodes 110, which will enable the mobile 
systems to work, will play a very important role in assuring 
that the mobile user can access all the data required. It is 
crucial for customers and manufacturers to certify that the 
15 infrastructure will work as desired under stress conditions 
and particular traffic types even in the most busiest hours. 
This is necessary in order to determine whether a product 
matches the performance requirements of a deployment 
scenario. 

20 The purpose of the invention is to develop methods to be 
adopted for testing the Gn 120 and Gi 121 interfaces in the 
GGSN node 110. The methods according to the invention enable 
a proper and extensive test of GTP-capable nodes 110-113 as 
GTP-capable nodes are deployed into a network 100 which has 

25 to serve several thousands users and offer them the required 
internet type of service. The Gn 120 and Gp 122 interfaces 
are the same from the point of view according to the present 
invention and are only considered to be between SGSNs 111- 
113 or between SGSN 111-113 and GGSN 110. Therefore we will 

30 only refer to the Gn 120 interface from now on. Also, the 
invention is applicable to both GPRS and UMTS, therefore 
further references to GPRS or UMTS hold for both systems. 
Following is the Gn 120 interface protocol stack. 
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Two types of interfaces are considered in the invention: IP 
interface and GTP-capable interface. An example of the IP 
interface is the Gi 121 interface in the GPRS/UMTS network. 
For this reason the name Gi 121 interface will be preferred 
5 and will indicate any such IP interfaces. The terms GTP 
capable interface and Gn 120 are assumed to have the same 
meaning. The Gn 120 interface name will be therefore used , to 
indicate any GTP capable interface of a GTP capable node. 

However, one skilled in the art will recognize that the 
10 interface naming in other iinplementations of the GTP capable 
node may differ from the one for GPRS used in the invention. 
The terms Gi 121 interface and Gn 120 interface should 
therefore always be considered representative of any IP 
interface and GTP capable interface respectively in a GTP 
15 capable node. 

The GTP capable nodes may have some different logical 
functions. For this reason we will distinguish, when 
appropriate, a GTP downstream node (SGSN 111-113 in the GPRS 
implementation) from a GTP upstream node (GGSN 110 in the 

20 GPRS implementation) . The term GTP node in according to the 
invention identifies a node with GTP capability regardless 
of its logical functionality. The actual node under 
examination should be inferred from the interfaces under 
test. For example if an IP interface is mentioned (i.e. Gi 

25 121) the node under consideration could not be a SGSN 111- 
113, as the current standards do not allow any such 
interfaces for carrying data traffic. 

According to the invention two testing procedures are 
described, with some sub-procedures, to assess the 
30 performance of GTP nodes. Such procedure involves a Testing 
device 130,310 (which generates and analyses packets) and 
the GTP node under test. The Testing device 130,310 will 
generate packets towards one or more interfaces of the GTP 
node and will analyse these packets once processed by the 
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device under test. The packets generated will be transmitted 
at a varying rate and will contain certain fields or 
parameters which will also be varied in order to test the 
performance limits of the device under test. The most 
5 important parameters are contained in the IP and GTP header 
portions which are described in the section below. The 
parameters may be varied on a packet -by-packet basis or 
every n-packets as specified later. 

The GTP packets contain certain fields or parameters of 

10 which the most important are contained in the header. The 
GTP header encapsulates the IP/UDP 201 or IP/TCP 202 data 
shown in FIG. 2 in order to direct data to the user in a 
correct manner. The GTP header format is shown in FIG. 4 
(taken from 3GPP spec 09.60 or 29.060). Two values in the 

15 GTP header are important to the scope of this document: 
Tunnel Identifier 403 and Sequence number 402. The TID 
(TiHinel ID) identifies a PDP Context. A PDP Context is 
'^activated" for a user to provide the user with a data 
connection having certain parameters and is assigned a TID. 

20 Therefore GTP traffic with the same Tunnel ID (TID, The TID 
parameter in rel.97 change name to Tionnel End Point in 
rel.99. The fxmction of the parameter does not however 
changes throughout the releases.) is traffic belonging to 
the same user (each active user having at least one TID /PDP 

25 Context assigned) . The Sequence Number 402 is a parameter 
that varies incrementally for each GTP packet with the same 
TID. It identifies the sequence of packets to/ from a certain 
user in a given PDP Context. The Message Type 401 identifies 
what the GTP packet is carrying. This may be data 

30 (identified as T-PDU) or signalling. In the latter case the 
code contained in this field will identify exactly what 
signalling message is being transported. The settings for 
other parameters is described in 3GPP dociaments and is not 
considered in this invention. 
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The traffic load will involve one or more pairs of 

interfaces of the node under consideration. The input/output 

interface combinations of Gn 120 to Gi 121, Gi 121 to Gn 120 

and Gn 120 to Gn 120 are considered by a specific testing 
5 sub-procedure specified later. 

Procedure B is concerned with loading the GTP node. Most of 
the parameters are kept to fixed values and the sub- 
procedure which tests the GTP node behaviour is run in order 
to test the individual parameters tinder consideration. The 
10 node will be loaded with traffic for some fixed nuinber of 
seconds (X seconds are needed to experiencing performance 
degradation, where X is a value between 5 and 600) • The 
different sub-procedures specify how to perfoairm the 
measurement. 

15 Following are the main parameters to be varied in the two 
procedures . 

1. The nxutvber of active PDP contexts 

2 . Traffic load per PDP context 

3. Line rate supported by the node 

20 4.N\unber (and configuration) of APNs (Access Point Names) 

5. Direction of traffic load 

6 . Frame size 

It is also investigated how the node under test copes when 
packet fragmentation is forced to occur in the node. 

25 The proposed solution is divided in three main sections: 
test setup, . procedures and form of results. The Test Setup 
section is concerned with test-bed setup. The actual test 
procedure is divided in two stages. The first one is for 
signalling where the testing focuses on the activation (and 

30 speed of activation) of the desired number of PDP contexts. 
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The second stage involves load testing. In both stages a 
number of parameters need to be set. These are then varied 
according to the sxib-procedures . By changing only one 
parameter at a given time it is possible to make that 
5 parameter accountable for performance degradation. 

The procedures and sub-procedures explain how to vary the 
parameters. Every test will be run without changing the 
configuration of the GTP node or setup of the testing device 
130/310 in any way during each part of the test. 

10 The last section presents some guidelines on parameter 
settings that need to be reported together with the results 
found. 

Test setuip 

FIG. 3 illustrates an example of the general setup to be 
15 used during the tests according to the invention. Two On 
321,323 and two Gi 322,323 interfaces in the GTP node 320 
are used in this example. The number of interfaces to be 
tested at the same time may however vary as explained in 
more details in procedure B, svib-procedure 7 . The dashed 
20 arrows 332,335 show the initial phase illustrated by 
procedure A when the GTP signalling is performed. The other 
arrows 331,333,334,336 in FIG. 3 illustrate the direction of 
the traffic load from the Gn 321,323 interface to the Gi 
322,324. That direction may be reversed or changed as 
25 explained in procedure B, s\ib-procedure 4. 

The testing according to the test setup in FIG. 3 is 
performed with two separate boards 311,313+312,314 belonging 
to the same testing device 310- This setup should be 
preferred in case a broadcast medium, such as Ethernet, is 
30 used as link between . the testing tool 310 and the GTP node 
320 in order to avoid possible degradation of performance 
caused by the medium itself when a heavy load is ej^ected. 
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One or multiple testing devices /boards 310,311-314 may be 
used as appropriate. 

A series of GTP capable nodes 110,320 may be also connected 
in cascade between the receiving testing device 310 and the 
5 sending testing device 130,310 as explained in procedure B, 
sub-procedure 8- 

6TP node minimal configuration 

Before beginning the test, a certain minimum number of 
parameters needs to be set in the GTP node. Minimal 

10 configuration indicates the different operations and 
parameters setting that needs to be performed in order to 
have the node imder test to be up and running. This includes 
IP address assignment to every interface and internal 
processes as required by the vendor in order to have the 

15 node operational. 

The GTP node needs to have at least one Access Point Name 
(APN) set so that the first test on signalling a nuitiber of 
PDP contexts can be performed. 

Three stages 

20 The test is divided in three stages: preliminary MAC address 
learning, signalling (Procedure A) and data load (Procedure 
B) . 

Preliminary Address Zisaming 

This is a preliminary phase which does not provide any 
25 results but is required in order to obtain accurate results 
in the two successive stages of tests described in the 
following sections. The GTP node under test and the Testing 
device 130,310 will not be able to communicate unless they 
are aware of each. other's MAC or hardware addresses relative 
30 to the interfaces which are interconnected. In the case of 
Ethernet this MAC address is the Ethernet address. 
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Therefore, any testing results will be affected by this 
initial learning phase unless we make sure that testing 
commences only once this ''learning" phase is complete. 

In the case of the testing configuration given in section 
5 "DESCRIPTION OF RELATED ART" it is necessary for the GTP 
node under test to learn" the MAG addresses of the four 
boards /interfaces 311-314 on the Testing device 130,310. 
This can be performed in two ways: 

1) by having the Testing device 130,310 use ARP messages 
10 informing the GTP node under test of the IP address to MAC 

address mappings 

2) by manually configuring on the GTP node the MAC 
addresses of the Testing device 130,310. 

Signalling and Signalling Load 

15 The preliminary part of every load test consists of setting 
up the data connections for the fictitious user/s (PDP 
Contexts) . The tests described in this section will take 
this further and assess the maximum number and rate of PDP 
Context activations which the GTP node under test can 

20 support. 

At this stage the test equipment generates the signalling to 
be sent into the GTP interface. The signalling contains all 
the parameters for the PDP context activation. The GTP 
header contains a ''Message Type" 401 field which identifies 
25 the type of signalling message (e.g. PDP Context Request) . 
This GTP header is followed by Information Elements (IBs) as 
shown in FIG. 5. 

Some mandatory Infoimation Elements (lEs) need to be 
contained in the GTP payload for a ''Create PDP Context 
30 request" message to be accepted by the GTP node under test 
(GTP upstream node, GGSN 110 in GPRS /UMTS) . Some of these 
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lEes (The lEs here listed are the mandatory parameters as 
listed in the GSM rel. 97 specification. Such parameters may 
vary depending on the release being implemented in the GTP 
node) are: Quality of Service Profile, Selection Mode, Flow 
5 label Data I, Flow label Signaling, End User Address, Access 
point Name, SGSN 111-113 Address for signalling, SGSN 111- 
113 Address for user traffic and MSISDN. Since the focus of 
the test is on loading the GTP node, the lEs to be sent to 
the node as part of the ''Create PDP context request" message 
10 will be the ones listed as mandatory in the GSM release 
supported by the node under test. 

In the GTP header, the message type field 401 identify that 
this message is a ^'Create PDP Context Request" (See GSM 
09.60, GPRS Tunnelling Protocol (GTP). across the Gn 120 and 

15 Gp 122 interface'', Release 1997, for GSM specification 
release 97) . The "'Create PDP Context Request" message will 
contain a static TID, APN and End User Address, thus 
establishing an association between the TID, the APN and the 
End User Address. Such associations are important in 

20 procedure B for sub-procedure 2 and 3, where the traffic is 
injected from the Gi 121 to the Gn 120 interface, and in 
sub-procedure 5, where load respect to the number of APN is 
illustrated. Also the traffic injected from the Gn 120 to Gi 
121 will use such an information, but the testing device 

25 130,310 does not need to be aware of that. Therefore sub- 
procedure 1 will not mention such associations. 

The testing device 130,310 will generate a "Create PDP 
Context Request" for the required niamber of PDP Contexts, 
thus emulating the behaviour of the GTP downstream node. In 
30 this case the sxibsequent ''Create PDP Context Response" 
message reply from the GTP upstream node (i.e. the node 
under test) to the testing device 130,310 may be ignored. 

Traffic load 
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The second stage of test is concerned with sending the 
traffic load into either the Gn 120, the Gi 121 or both 
• interfaces. The GTP node under test is configured to perform 
APN routing and/or IP (vanilla) routing as defined by 
5 procedure B, sub-procedure 3, The packets are therefore 
processed by the GTP node and data traffic is sent back to 
the receiving testing tool which uses its data capture 
functionality to check for errors, packet losses and 
latency. This feedback process will provide a way of 
10 measuring the packet loss rate and latency as a way of 
assessing performance degradation. To assess the performance 
of the GTP node, a n\iitiber of parameters need to be varied 
from (generated) packet to packet according to the type of 
test. 

15 Procedures for Load testing 

The following sections describe two procedures to be used 
when load-testing the GTP node. As already mentioned, 
testing one parameter usually implies that the rest are kept 
constant in all packets transmitted. At the end of procedure 
20 B an example of initial parameter settings is given. 

Procedure A: to determine xaaximum nuinber o£ PDF contescts 
supported by the GTP capable node 

For this phase of the test only the minimal configuration of 
the GTP node is required. This procedure will be applied 
25 only to the GTP nodes that support the PDP context 
activation fxmctionality (At the present time in the GPRS 
implementation only the upstream GTP node, GGSN 110 and not 
the downstream. ) . 

Sub-procedure 1: Max nuxniber o£ PDP context activations 
3 0 supported 

According to the invention in a method data packet /s are 
sent and data packet/s are processed in the folowing steps: 
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a) activating a nuiriber n of the PDF context /s into the 
network node (GTP capable node) , where n is a determined 
niamber ; 

b) analyzing the m data packet/s in the analyzing phase, and 
5 if the failure is occuring 

c) starting step h, and if the failure is not occuring 

d) resetting and clearing the network node (GTP capable 
node) of activated n number of PDP context/s; 

e) activating a doubled n number of PDP contexts in the 
10 network node (GTP capable node) ; 

f ) analyzing the m data packet/s in the analyzing phase ^ and 
if the failure is not occuring 

g) repeating step d-f, and if the failure is occuring 

h) resetting and clearing the network node (GTP capable 
15 node) of activated m number of PDP context/s; 

i) activating a number m of PDP context/s, wherein setting m 
equal to n/2 plus n/20; 

j) increasing the m number with n/20; 

k) analyzing the data packet/s in the analyzing phase, and 
20 if the failure is not occuring 

1) repeating step h-k, and if the failure is occuring 
m) recognizing the m number minus n/20 as the maximum M 
number of PDP context/s that is possible to activate. 

During the signalling part the required PDP contexts are 
25 activated. For each PDP Context to be activated, a packet is 
transmitted by the Testing device 130,310 to the GSN Node 
under test. This packet contains a GTP header identifying 
that it is a ''Create PDP Context Request" message. One of 
the mandatory lEs it will contain is the TID IE. For each 
30 PDP Context to be activated the TID will be incremented by 
one, starting from zero. Therefore in this activation phase 
every consecutive PDP Context will be requested to be 
associated with a different TID. Although the TIDs (or PDP 
Contexts) are different one or more of them may belong to 
35 the same fictitious user. 
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It is reasonable to expect that the inter- frame gap for 
messages containing such signalling is reasonably high in 
such a way that the maximum number of PDF contexts that can 
be activated is not affected in the first stage by 
5 limitations in PDP Context activation speed of the node 
under test (PDP Context activation overload) . A reasonable 
value is 100 thousand times the minimum gap allowed by the 
media type on the interface considered (In case of a 10 
Mbit/s Ethernet, the minimum inter frame gap is 96 bits. One 

10 himdred thousand times the minimum gap is 9600000 bits which 
covers almost one second. One second is considered a long 
enough time period for the signalling frame to arrive at the 
GTP node without causing any problems due to signalling 
overload in ther node under test.)- After the signalling 

15 part has been performed, it is necessary to verify whether 
the activation of all the PDP contexts has been successful. 
This may be done in two ways: by looking if the PDP contexts 
have been activated in the GTP node or counting the PDP 
context activation responses in the testing device 130,310. 

20 The signalling process can be repeated in steps to find out 
the number of PDP contexts that may be supported at one time 
from the GTP node. In order to find the max number of PDP 
context the following method is employed. The number of PDP 
Contexts to be activated starts from a relatively small 

25 number (e.g. 100 PDP contexts) and it is verified that the 
node can support them. After that, the node under test is 
reset or cleared of the activated PDP . Contexts - Then another 
test is performed in which the number of PDP contexts 
activated is doubled. This procedure is repeated until the 

30 node fails the test (i.e. fails to activate one or more PDP 
Contexts) . At that point, the number of PDP context requests 
supported by the node will be in between the previous 
successful test and the failed test. A ''divide and conquer" 
binary search should be used recursively several times in 

35 order to home in on the accurate maximum number of PDP 
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contexts that can be accepted by the node. The load is not 
considered at this stage. 

Sub-procedure 2: Maxixnum speed supported for subsequent PDF 
Context Activations and successful rate 

5 After having foiind the maximum number (M) of PDP contexts 
that can be handled in a condition having slow arrival of 
activation requests, the gap between the different GTP 
signalling frames should be varied. This is to give the 
measure of how fast the GTP node can handle consecutive PDP 
10 context activations and at what stage the node can be 
overloaded with consecutive activation requests. Two options 
are described in order to find the speed at which a certain 
nxHTiber of PDP contexts may be activated. 

The first method is used to find the maxiimmi activation 

15 request rate at which all the PDP contexts are successfully 
activated in the GTP node. For this scope a method of divide 
and conquer is employed. The method consists in sending a 
n\mber of M or less PDP context activations to the GTP node 
and verifying that they have been successfully accepted. The 

20 starting speed may be set in such a way that the inter-frame 
gap is 100 thousand times the miniimom inter- frame gap 
allowed by the media. If that gap leads to a failure, then 
the gap may be doiibled. This procedure may be repeated as 
many times as necessary. However if a failure is experienced 

25 for K consecutive times (where K is an integer between 2 and 
20) then the maximum speed may not be determined using this 
method and the second method may be used to determine the 
degradation in performance. Otherwise if the first test in 
this series (gap equal to 100 thousand times minimum gap) 

30 leads to a successful test, then the gap will be halved 
until a failure condition is experienced or the ininimum 
inter- frame gap allowed by the media is tested. When the 
failure is experienced, the gap value will be the middle 
value between the last successful and the failed gap value. 
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The procedure will be repeated with the binary search in 
order to home in on an accurate value of gap (PDF Context 
activation rate) supported by the node under test. 

The second method instead analyses the performance 
5 degradation as the rate of PDF Context activations 
increases. Such degradation may be acceptable in certain 
instances, but it is nevertheless necessary to provide this 
measurement when assessing node performance. In order to do 
that a number equal or less than M of PDF context (i.e. e.g. 

10 M * 80%) will be sent at a constantly increasing rate for 
every subsequent test towards the GTP node. To do this the 
gap will reduced every test by a certain ammount \intil the 
minimal gap value for the media has been reached. The ratio 
of the PDF contexts activated in the GTP node should be 

15 recorded in percentage for every single case so that 
performance degradation may be measured. 

Procedure B: to load GTP node with GTP traffic per activated 
PBP Context 

Once the signalling phase has been performed and the 
20 necessary number of PDF Contexts have been activated, the 
actual load may be injected. 

Procedure B is broken up into several sub-procedures. The 
order and combination of the sub-procedures is not relevant 
for the whole procedure and these may be carried out in a 

25 different order. As a person skilled in the art appreciates, 
application of the invention is in no way limited to that a 
particular order may be followed. Different variables are 
the subject of the test of different subprocedures , so it 
may be decided that some variables are more iiriportant of 

30 some others if time is a big constraint of the test. The 
single sub-procedure will usually be implemented keeping 
some of the other variables to fixed values. The same sub- 
procedure may then be repeated with some other fixed values 
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as required. 

Either sub-procedure 1, 2 or 3 always needs to be included 
as part of all tests, as it specifies the way to perform the 
measurements. For procedure B the load will be sent 
5 following the sub-procedure 1 only when the GTP node input 
interface is the Gn 120 interface. 

Certain parameters and settings may be set and modified 
before beginning the complete Procedure B test composed of 
one or more sub-procedures. These parameters are: 

10 • Number of interfaces involved in test 

• Fragmentation (forced) 

• Cascading of nodes under test 

This first item is concerned with the number of simultaneous 
interfaces under test. The nturiber of interfaces on the 

15 Testing device 130,310 and node under test to which the load 
is sent to and received from can be increased from one to 
many (in the example of testing setup in chapter "TEST 
SETUP" it is set to two) . Such an increase in the number of 
GTP node interfaces under simultaneous test can be done in 

20 steps of n where a typical value of n is 1. Therefore a 
complete Procedure B test may be performed per interface 
configuration. The simultaneous use of separate interfaces 
is only possible when the testing device's boards 311-314 
are communicating in a way that connects them and siimilates 

25 a single testing device 130,310. 

The second item in the list above is used to measure how the 
node under test can handle fragmentation. If the same 
technology is used on the Gi 121 and Gn 120 interfaces, then 
a maximum frame size frame sent into the Gi 121 will be 
30 fragmented (in 2 frames) on the Gn 120. In a GTP node we are 
also interested with the fragmentation happening between Gn 
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120 interfaces when the outgoing interface media type 
supports a lower MTU (Maxinnjin Transmission Unit) than the 
incoming interface. Fragmentation may also happen with load 
from Gn 120 to Gi 121 when the Gn 120 MTU is greater by a 
5 certain amount than the one supported on the Gi 121 
interface and maximum size frames are used on the Gn 120. 
When such fragmentation is forced in these test settings an 
appropriate way of reconciling the count of received and 
transmitted packets is necessary otherwise it may appear 
10 that more packets are received than those which are sent. 

The last item of the previous list has to do with putting 
multiple GTP nodes in cascade, between the testing device's 
130,310 sending interface and the testing device's 130,310 
receiving interface. The results of the test should clearly 
15 state the number of GTP nodes and their models when the 
results are presented. 

Once the appropriate sub~procedures have been combined and 
the whole Procedure B test has been performed (according to 
previous test settings), one of the following may be done: 

1. the node under test is reset and the whole test procedure 
or some particular part of one or more sub-procedures is 
repeated 

2. the PDP Contexts are ''deleted" without resetting the node 
under test, and the whole test procedure or a part of one 
or more sub-procedures is repeated 

Case 2) is useful to stress- test the node under constantly 
changing conditions. It is therefore possible that one or 
more repetitions of the procedure in Case 2) will yield 
different results at each iteration. Should the performance 
30 degrade this would demonstrate limitations in the node \inder 
test. 



20 



25 
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Sub-procedure 1: 6n to Gl anA Qxx to 6n load testing for 
activated PDP contexts 

The direction of traffic in the tests follows these cases: 

Case 1 Traffic from Gn 120 to Gi 121 (no traffic Gi 121 
5 to Gn 120 and Gn 120 to Gn 120) 

Case 2 Traffic from Gi 121 to Gn 120 (no traffic Gn 120 
to Gi 121 and Gn 120 to Gn 120) 

Case 3 Traffic from Gn 120 to Gn 120 (no traffic Gn 120 
to Gi 121 or viceversa) 
10 Case 4 Traffic mix: Gn 120 to Gi 121 p%, Gi 121 to Gn 120 
n%, Gn 120 to Gn 120 100-p"n% with p+n ^ 100- 

Cases 1 and 3 are performed according to this sub-procedure, 
while case 2 is described in sub-procedure 2 and case 4 (a 
15 generalisation of cases 1, 2 and 3) is described in siob- 
procedure 5 . 

A different TID is allocated to each active PDP Context 
normally by the Testing device 130,310 upon PDP Context 
activation. Once a number (N) of PDP contexts are activated/ 
20 the actual load may be sent from the Testing device 130,310 
to the Gn 120 interface (s) of the GTP node in different ways 
as given below: 

1. Same number of GTP packets transmitted by Testing device 
130,310 per PDP context (TID). Every packet is sent with a 
25 different TID until all TIDs are served. When the last TID 

has been reached, the process is repeated starting from 
the first TID. In this case all the packets will have the 
same sequence nxamber until all the PDP contexts (TIDs) 
have been spanned as shown in the example below in TAB. 2. 

30 N - Number of active PDP Contexts (TIDs) 

Y - Total number of GTP packets transmitted in test 
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Packet 
No. 


TID 


Seq. 
Number 


1 


1 


0 


2 


2 


0 






0 


N 


N 


0 


N+1 


1 


1 




2 


1 








Y 


N 


(K/N)-l 



TAB. 2 



2. An equal number of IP packets per TID are transmitted by 
the Testing device 130,310, see TAB- 3, where bursts of n 
5 packets are transmitted consecutively having the same IP 

address. The procedure will repeat for every user \antil 
the maximum number of packets to be transmitted in the 
test is reached (identified by variable Y) . Variables N 
and Y are described previously. 



Packet 
No. 


TID 


Seq. 
Number 


1 


1 


0 


2 


1 


1 


3 


1 


2 
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N 


1 


N 


N+1 


2 


0 








Y 


N 


N 



TAB. 3 

3. A different niiinber of consecutive packets are sent for 
each TID. The niiitiber of packets per user may be 
statistically distributed or randomly distributed. 

5 Sub-procedure 2: Gi to 6n load testing for activated PDP 
contexts 

For generating the load to be sent into the Gi 121 
interface, the Testing device 130,310 sends IP packets 
addressed to the range of IP addresses that have been 
10 associated to each TID within the PDP context activation 
phase (during the signalling part) as explained in chapter 
Signalling and Signalling Load" . 

This test will be performed by sending IP packets to the IP 
destination address as set in the End User Address of the 
15 PDP context. The following options are available when 
loading the node -under test during this test: 

1. Same number of IP packets are transmitted by the Testing 
device 130,310 per TID. Every packet is sent with a 
different IP destination address until all the TIDs are 
20 served in a round- robin manner, see TAB 4. When the last 

TID has been reached, the process is repeated starting 
from the first user. 

N - Number of active users 



wo 02/51 181 PCT/SEOl/02881 

23 



Y - Total number of IP packets transmitted in test 



Packet 
No. 


TID 


1 


1 


2 


2 






N 




N+1 


1 




2 


• • 




Y 


N 


TAB 


. 4 



2. An equal number of IP packets per TID are transmitted by 
the Testing device 130,310, where bursts of n packets are 
transmitted consecutively having the same IP address. The 
procedure will repeat for every user until the maximum 
niunber of packets to be transmitted in the test is reached 
(identified by variable Y) , see TAB. 5. Variables N and Y 
are described previously. 



5 



10 



Packet 
No. 


TID 


1 


1 


2 


1 
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3 


1 






N 


1 


N+l 


2 






Y 


N 


TAB 


. 5 



3. A different nuiriber of consecutive packets are sent for 
each TID. The number of packets per user may be 
statistically distributed or randomly distributed. 

5 Every IP address corresponds to a different user. Different 
TIDs may have the same End User Address associated with 
them. The sub-procedure at this stage does not coiont the 
nimiber of TIDs generated in the signalling section of the 
test, but the number of different IP addresses associated 

10 with them. A user will be active if the corresponding IP 
address has at least one activated PDP contexts. The 3 
methods reported above can therefore be extended on a "^per 
user" basis rather than ''per TID'' basis as reported in the 
tables above. The ''per user basis" method does not provide 

15 the same level of granularity based upon the nunnber of 
associated TIDs as in the previous methods (i.e. a user may 
have more than one TID associated to it) . 

Sub-procedure 3: Bidirectional load traffic distribution on 
Gi ajid 6n interfaces 

20 The load here follows the general formula for a mix of 
traffic {from a total expressed as 100%) : 



Gn to Gi traffic' = 
Gi to Gn traffic = 



p% 
n% 
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Gn to Gn traffic = 100-p-n% 
where p+n £ 100 

The way in which the load is applied is a combination of 
sub-procedure 1 (for traffic Gn 120 to Gi 121 and Gn 120 to 
5 Gn 120) and sub-procedure 2 (for traffic Gi 121 to Gn 120) . 

The load direction will be at the beginning only going from 
Gn 120 to Gi 121 (p=100, n=0) as in sub-procedure 1. The 
bidirectionality will be enforced in small steps that 
increase the value of n by x% (say n starts from a value of 
10 1%) and decrease p appropriately to maintain p+n < 100 until 
p=0 and n=100 (as described in sub-procedure 2) . Variable x 
can be any positive integer (e.g. 20%) . 

This does not consider Gn 120 to Gn 120 traffic (i.e. 
previously p+n=100%) . When Gn 120 to Gn 120 traffic is 

15 present then p+n<100%- In this case the value of 100-p-n is 
set to a number between 1 and 100%. TOien this value is equal 
to 100% only Gn 120 to Gn 120 traffic is present and this 
case is described in siib-procedure 1. When 100>100-p-n<l the 
amount of load between the interfaces can be varied in a 

20 similar way to the procedure described earlier. The value of 
p or n can be set to its maximum (i.e. say that 100-p-n=:l 
then pmax or x^nax = 99) decreased in steps of x% until the 

variable se initially to its maximum value reaches its 
minimum (e.g. say that 100-p-n=l then Pndn or nmin = 0) . As 

25 before x can be any positive integer (e.g. x=20%) . 

Sub*procedure 4: How to increase the packet rate 
(packets /second) as a fraction of the xnaximuiQ line rate and 
measure the performance degradation 

According to the invention in a method data packet /s are 
30 sent and data packet/s are processed in the folowing steps: 
a) sending a number n of data packet/s to the network node 
(GTP capable node) at k% of maximum line rate supported by 
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the network node {OTP capable node) , where n and k are a 
determined numbers; 

b) increasing the line rate in steps of p%, setting k=k+p; 

c) analyzing the data packet/s in the analyzing phase, and 
5 if the failure is not occuring 

d) repeating step a-c, if the failure is occuring 

e) sending n number of data packet/s to the network node 
(GTP capable node) at that line rate before failure occuring 
plus q% of maxirnum line rate supported by network node (GTP 

10 capable node) , where q is a determined number; 

g) increasing the line rate in steps of u%, setting q=q+u, 
where u is a deteirmined number; 

h) analyzing the data packet/s in the analyzing phase, and 
if the failure is not occuring 

15 i) repeating step e-h. 

This sub-procedure illustrates two methods. Every packet 
sent by the Testing device 130,310 to the GTP node contains 
a certain pattern in the data portion of the GTP packet. 
When the packet is sent back from the node to the Testing 
20 device 130/310 that pattern may be analysed for integrity 
and to trigger the counting of correctly received packets. 

The sub-procedure counts the following: 

1. number of packets transmitted by the Testing device 
130,310 (should be the same for all tests) 

25 2. ntairiber of packets received by the Testing device 130,310 

3. number of packets received containing a certain pattern 

The difference between 1 and 2 (i.e. 1 minus 2) is the 
nvmiber of packets lost by the GTP node, while 1 minus 3 
accounts for the number of packets that are sent back to the 
30 testing device 130,310 with some errors. The percentage link 
rate at which no errors are found will be the maximum 
supported link rate. If the difference between 1 and 3 is a 
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niaiiiber different from zero, then the GTP node cannot support 
that throughput (percentage of link rate) and presents 
performance degradation. The same stands for lost packets. 
Therefore the methods einployed by the sub-procedure will be 
5 explained only for packet with errors, since the number of 
packet losses can be found in a similar way. 

The first method measures the maximum line rate supported by 
the node. The packet rate is increased from a small fraction 
of the media maximum line rate (e.g. 10%) in steps of x% 

10 (e.g. 20%) until the percentage of link rate is reached 
where errors are found. From that point a mechanism of 
binary search, like divide and conquer, is employed to home 
in on the exact percentage of the link rate supported. The 
same result can be achieved by starting from the full line 

15 rate and decrementing the percentage down in steps before 
using the binary search. 

The second method is concerned with performance degradation. 
The measurements are done by. varying the load entering the 
interface \ander consideration from 100% of the max line rate 

20 decrementing in steps of x%. An alternative is incrementing 
the load in steps of x% starting from a minimum value (e.g. 
10%) of the maximum line rate. The measurements will 
consider the percentage of packets that are received without 
errors for each given value of load injected as a fraction 

25 of the line rate. Forms of results: a graph can be produced 
with the percentage packet loss versus the percentage of the 
line rate. The measurement of the packets containing errors 
or the packet loss can be done on a PDP Context basis or on 
an aggregate basis. 

30 Sub-procedure 5: Traffic loading with respect to nuxhber of 
APNs and their configuration (APN Routing) 

The number and type of APNs must be first configured in the 
GTP. To test the APN routing and how fast the APN lookup is 
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done in the GTP node, PDP Contexts must be activated having 
different APNs. In the early tests, the subprocedures 
described previously are run having all PDP contexts 
associated with the same APN. The load is then applied to 
5 the GTP node \mder test and the percentage of packet loss is 
measured (see sxab'-procedure 2) . As different APNs are 
associated to different PDP contexts these tests can be run 
again ( s\ib-procedure 2) . The results will then account for 
possible degradation in performance due to APN routing. Such 

10 a degradation may occur because the node is stressed as the 
packets received from the Testing device 130,310 force it to 
perform continuous APN routing lookups (i.e. matching 
incoming TID to outgoing interface and viceversa) • The 
different TIDs (having associated APNs) will be evenly or 

15 unevenly associated to the packets generated by the Testing 
device 130,310. 

In TAB. 6 is shown an embodiment according to the invention 
with 3 APNs and even round-robin distribution of packets per 
APN, 



Packet no. 


APN 


1 


A 


2 


B 


3 


C 


4 


A 


5 


B 


6 


C 






TAB 


. 6 



The exaitple in TAB. 6 show the AEN distribution per packet 
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sent. Such a distribution forces the node to do extensive 
APNs lookup and put the node in the worst condition in terms 
of APN routing lookups. 

However the load may be sent to the node without a 
5 particular sequence of packet per PDP context (method 3 of 
sub-procedure 1 and 2) . In this case the example above does 
not apply. 

The number of APNs can be increased as required- This 
maximum number may be reached in steps that double the APNs 
10 in use at every step. At the moment of writing 100 APNs is 
considered to be a very high mjunber so it may be used as a 
maximum value. 

This sub-procedure also defines which kind of routing the 
node should perform. The GTP node, depending upon the way it 
15 has been set, can perform only APN routing, only (noimal) 
vanilla IP routing or a mix of both types of routing. The 
results of the test should state the percentage of APNs used 
that are associated to APN routing and the percentage that 
does IP vanilla routing. 

20 Sub-procedxire 6: Freime size variation 

The frame size should include the maximum and minimum size 
allowed by the media type. The frames can be sent all with 
the same frame size or mixing together frames with different 
sizes trying to reflect the percentage of each type of frame 
25 in real-world traffic. However such an approach may be 
difficult to implement and the issue of trying to implement 
real-world traffic frames may be addressed in part by 
sending frames reflecting the average size (some estimations 
give an average frame size of 300 bytes) . 

30 This sub-procedure, however, includes tests with several 
frame sizes including the maximum and minimum allowed. This 
is to appreciate the difference in the node performance 



wo 02/51181 



30 



PCT/SEOl/02881 



depending on the packet size. The packet size will be varied 
for every test with steps of X bytes between the maximim and 
minimum size. Variable X can be any number of bytes from 1 
to (max size - min. size) . The rule for incrementing the 
5 packet size from the smallest to the maximum size allowed 
will be: 

New frame size = min size + n X 
Where n is an integer such that: 
Min size + nX < max. size 

10 A similar method can be applied in case the frame size is 
decremented from the max size to the minimum size. 

Following is an example of max and minimum frame size 
applicable to Ethernet frames. 

The maximum Ethernet frame the size is 1518 bytes. The 
15 minimum realistic size frame has been calculated in the case 
of VoIP application where we have 20 bytes for IP header, 8 
for UDP (User Datagram Protocol), 12 for RTP and 30 for 
coded speech (70 bytes in total) . Therefore the length of 
the Ethernet frame is 70 + 20 (GTP) (The GTP header length 
20 is 20 bytes in release 97 while is 12 for release 2000. The 
value of the minimum Ethernet frame may therefore change to 
reflect the change in the GTP Header. ) + 8 (UDP) +20 (IP 
transport) + 18 (Ethernet) = 136 bytes. 

Sub-procedure 7: Gn to Gi and Gn to Gn Latency measurexnants 

25 Latency is the measure of a packet's delay from the moment 
in time it leaves the sending Testing device's 130,310 
interface to the moment it reaches the receiving one. 

This sub-procedure is run as described for sub-procedure 1 
and 4. The only difference is that, instead of packet loss 
30 or errors, the inter-packet delay on a PDP Context . basis, 
user by user basis or on aggregate basis is measured. 
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Results in terms of latency measurements are used to 
evaluate the processing speed and queuing disciplines of the 
GTP-capable node under different load conditions. 

Sub-procedure 8: Gi to Gn Latency measurements 

5 This sub-procedure is run as described for s\ib-procedure 1 
and 4. The only difference is that, instead of packet loss 
or errors, the inter -packet delay is measured on a PDP 
Context basis, on a user by user basis or on aggregate 
basis. The definition of latency is given in the previous 
10 sub-procedure . 

Example of Procedure B implementation 

Following is an example illustrating how the subprocedures 
can be combined in order to achieve the desired performa.nce 
testing. The steps are illustrated below: 

15 • One single GTP node will be tested, and the OTP node will 
have only a peer of boards 321-324 for input /output 
(described in Procedure B chapter "Procedure B: to load 
GTP node with GTP traffic per activated PDP Context") 

• The number of APNs in use will be fixed to 1. See sub- 
20 procedure 5 on how to vary the nuinber of APNs 

• The frame sizes will be fixed to a certain value that does 
not force fragmentation (see sub-procedure 6) 

• For the procedure B, the first test involves checking the 
maximum line rate {sub procedure 2) using one of the 

25 methods illustrated by sub-procedure 1 and sub-procedure 

4. The traffic will be unidirectional from Gn 120 to Gi 
121. 

Form of expected results 

The result should have the form of a number when a binary 
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search (divide and conquer) has been used. VJhen the node 
performance degradation measxirement is taken, a graph is 
e:}qoected. The numbers found with the binary search may be 
summarised with a graph when only one variable is changed 
5 and the rest kept constant. In that case the plot will 
involve the changing variable versus the different results 
very often expressed as percentage of success. 

In every case the results must always come together with the 
• full specification of the setting of the variables in use 
10 even if they never change. A special part should be reserved 
to the frame format as explained in the following point. 

Frame f ozmat 

The frame format will depend on the particular 
protocol /media combination and the test frame used should be 
15 reported together with the results. 

The combinations may be taken from those supported by the 
node. The results comparison will be done only between 
competitor nodes with the same type of interface which is 
the same protocol /media combination. 

20 Below are typical options for the application/network, link 
and media type that may occur in the interfaces of the node: 

Application, network: TCP/IP, UDP/IP, GTP/UDP/IP... 

Liiik: Ethernet, ATM, FR, PPP... 

Media Type: 10 - 100 Base T, El, E3, Tl... 



3GPP 


Third Generation Partnership 
Project 


APN 


Access Point Name 
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IEb 


Information Elements 


IETF 


Internet Engineering Task Force 


IP 


Internet Protocol 


GGSN 


Gateway GPRS Support Node 


GPRS 


General Packet Radio Service 


GTP 


GPRS Tunnelling Protocol 


MTU 


Maximum Transmission Unit 


PDN 


Packet Data Network 


PLMN 


Public Land Mobile Network 


RFC 


Request For Comments 


SGSN 


Serving GPRS Support Node 


TCP 


Transmission Control Protocol 


TID(TEID) 


Tunnel Identifier 


UDP 


User Datagram Protocol 


UMTS 


Universal Mobile 
Telecoiraminications Systems 



TAB. 7 
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1. A method for testing the performance of a network node 
(GTP capable node) in a radio communication system, 
said network node (GTP capable node) including at least 

5 one interface, 

characterised in that said method 
comprising the steps of: 

sending at least one data packet towards said at least 
one interface (Gi,Gn/Gp); 
10 processing said data packet/ s in said network node (GTP 

capable node) ; 

analyzing the data packet /s returning as a response to 
said sent data packet /s. 

2. A method according to claim 1, 

15 wherein said network node is • a GGSN node (Gateway GPRS 

Support Node) , and 

said interface/s is Gi or Gn/Gp interface/s. 

3. A method according to claim 1, 

wherein sending data packet /s towards at least one Gi 
20 or Gn/Gp interface from a testing devices- 

processing said data packet/s in a GGSN (Gateway GPRS 
Support Node) network nodes- 
analyzing the data packet/s returning as a response to 
said sent data packet/s in said testing device. 

25 4. A method according to any one of claims 1-2, 

wherein said sending data packet/s towards at least one 
interface (Gi,6n/6p) corresponds to sending data 
packet/s into either a Gi interface or. a Gn interface, 
or to both Gi and Gn interfaces. 

30 5. A method according to any one of claims 3-4, 

wherein an initial phase of said sending at least one 
data packets comprising: 

learning address/es relative to said interface/s 
SUBSTITUTE SHEET (RULE 26) 
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(Gi,Gn/Gp) of said network node (GTP capable node), 
said learning includes said testing device using ARP 
message/ s informing said network node (GTP capable 
node) of a MAC address mapping/ s corresponding to IP 
5 address/es of said testing device - 

6. A method according to any one of claims 3-4, 

wherein an initial phase of said sending at least one 
data packets comprising: 

learning address/es relative to said interface/s 
10 (Gi,Gn/Gp) of said network node (GTP capable node), 

said learning includes manually configuring a MAC 
address/es on said network node (GTP capable node) of 
said testing device. 

7. A method according to any one of claims 1-6, 

15 wherein an initial phase of said sending at least one 

data packets comprising the steps of: 

a) setting n=l, where n is the number of data packet; 

b) setting m=l, where m is the number of TID; 

c) setting p=l, where p is the number of APN; 

20 d) sending data packet number n including at least one 

GTP header with m different TID numbers, and number p 
associated APN to said network node (GTP capable node) ; 

e) doubling said number p; 

f) analyzing said data packet in said analyzing phase, 
25 and if said failure is not occuring 

g) repeating step a-f • 

8. A method according to claim 7, 

wherein said determined number p is corresponding to 
the number of APN associated to said network node (GTP 
30 capable node) . 

9. A method according to any one of claims 5-8, 
wherein, after said initial phase is performed, 
setting up a data connection with at least one 
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fictitious user (PDP context), by sending data packet/s 
into said interface/s (Gn/Gp) of said network node (GTP 
capable node) containing at least one parameter for PDP 
context activation. 

5 10. A method according to claim 9, 

wherein said parameter/s for PDP context activation 
including at least one GTP header containing a message 
type field identifying the type of signalling message, 
said signalling message being identified as a Create 
10 PDP Context, and said signalling message containing a 

TID (Tunnel Identifier) IE (Information Element) . 

11. A method according to claim 10, 
wherein said GTP header/s is containing: 

a static APN (Access Point Name) and a static End User 
15 Address associating each said TID (Tunnel Identifier) , 

or different APNs (Access Point Names) and a range of 
different End User Addresses associating each said TID 
(Tunnel Identifier) . 

12. A method according to any one of claims 10-11, 

20 wherein for each said PDP context activation said TID 

(Tunnel Identifier) value is incremented by one, 
starting from zero for each PDP Context activation. 

13. A method according to any one of claims 9-12, 
wherein, said sending data packet/s containing said 

25 parameter/s for PDP context activation, including said 

analyzing phase conprising the steps of: 
starting said analyzing phase including looking if PDP 
contexts have been activated in said network node (GTP 
capable node) ; 

30 determining if all PDP contexts are activated, and if 

not so a failure has occured. 

14. A method according to any one of claims 9-12, 
wherein, said sending data packet/s containing said 
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parameter /s for PDF context activation, including said 
analyzing phase comprising the steps of: 
counting said PDF context activation responses 
returning from said network node (GTP capable node) ; 
5 determining if the nTomber of activation response/s 

returning from said network node (GTP capable node) is 
equal to the number of PDF context/s activated, and if 
not so a failure has occured. 

A method according to any one of claims 1-12, 
wherein, said sending data packet/s, including said 
analyzing phase comprising the steps of: 
counting while sending a number n of data packet/s to 
said network node (OTP capable node) ; 

counting returning number m of data packet/s from said 
network node (OTP capable node) ; 

comparing sent n number of data packets with retiaming 
m number of data packets; 

determening if sent n nimiber is not equal to received m 
number, and if so a failure has occured. 

20 16. A method according to any one of claims 1-12, 

wherein said sending data packet/s, including said 
analyzing phase comprising the steps of: 
counting while sending a ntimber n of data packet/s to 
said network node (GTP capable node) ; 

25 counting returning m data packet/s including certain 

patterns from said network node (GTP capable node) ; 
coitparing sent n number of data packet/s with returning 
m number of data packet/s; 

determening if sent n nTmiber is not equal to retixming 
30 m n-urober, and if so a failure has occured. 

17. A method according to any one of claims 1-12, 

wherein said sending data packet/s, including said 

analyzing phase comprising the steps of: 

setting a timer when a first data packet is being sent 
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to said network node (GTP capable node) ; 

stopping said timer when said first data packet return, 

giving a latency delay of said first packet. 

18. A method according to any one of claims 9-17, 
5 wherein said sending data packet /s and said processing 

data packet/s comprising the steps of: 

a) activating a number n of said PDF context/s into 
said network node (GTP capable node) , where n is a 
determined number; 
10 b) analyzing said m data packet/s in said analyzing 

phase, and if said failure is occuring 

c) starting step h; and if said failure is not occuring 

d) resetting and clearing said network node (GTP 
capable node) of activated n nuiriber of PDP context/s; 

15 e) activating a doubled n number of PDP contexts in 

said network node (GTP capable node) ; 

f) analyzing said m data packet/s in said analyzing 
phase, and if said failure is not occuring 
. g) repeating step d-f , and if said failure is occuring 

20 h) resetting and clearing said network node (GTP 

capable node) of activated m number of PDP context/s ; 
i) activating a nimiber m of PDP context/s, wherein 
setting m equal to n/2 plus n/20; 
j) increasing said m number with n/20; 

25 k) analyzing said data packet/s in said analyzing 

phase, and if said failure is not occuring 
1) repeating step h-k, and if said failure is occuring 
m) recognizing said m ntariber minus n/20 as the maximum 
M number of PDP context/s that is possible to activate. 

30 19. A method according to any one of claims 3-18, 

wherein said sending data packet/s and said processing 
data packet/s conprising the steps of: 

a) sending a number n of data packet/s from said 
testing device to said network node (GTP capable node) 
35 with a number n of simultaneous interface/s (Gi,Gn/Gp) 
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on said network node (GTP capable node) and on said 
testing device, where n is a determined nuinber; 

b) increasing a nuniber n of simultaneous interface/ s 
{Gi;Gn/Gp) on said network node (GTP capable node) and 

5 on said testing device by steps of N, where N is a 

determined nimber; 

c) analyzing said data packet/ s in said analyzing 
phase, and if said failure is not occur ing 

d) repeating step a-c. 

10 20. A method according to claim 19, 

wherein said determined number N is corresponding to a 
step of 1. 

21. A method according to any one of claims 1-20, 
wherein sending data packet/s of a maximum frame size, 

15 including said analyzing phase comprising the steps of: 

analyzing fragmantation happening of said data packet/s 
due to said network node (GTP capable node) . 

22. A method according to any one of claims 1-21, 

wherein said sending data packet/s and said processing 

20 data packet/s comprising the steps of: 

a) sending a number n of data packet/s to said network 
node (GTP capable node) at k% of maximum line rate 
supported by said network node (GTP capable node) , 
where n and k are a detentdned numbers; 

25 b) increasing said line rate in steps of p%, setting 

k=k+p ; 

c) analyzing said data packet/s in said analyzing 
phase, and if said failure is not occuring 

d) repeating step a-c, if said failure is occuring 

30 e) sending n ntamber of data packet/s to said network 

node (GTP capable node) at that line rate before 
failure occuring plus q% of maxiimjm line rate supported 
by network node (GTP capable node) , where q is a 
determined number; 
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g) increasing said line rate in steps of u%, setting 
q=q+u, where u is a determined nuitiber; 

h) analyzing said data packet /s in said analyzing 
phase, and if said fail\ire is not occur ing 

5 i) repeating step e-h. 

23. A method according to claim 22, 
wherein setting said value k to 10; 
setting said value p to 20; 
setting said value q to 5; 

10 setting said value u to 1. 

24. A method according to any one of claims 1-23, 

wherein said sending data packet/s and said processing 
data packet/s comprising the steps of: 

a) setting g=m * minimum inter- frame gap allowed by 
15 media, where m is a determined number; 

b) sending a number n of data packets to a network node 
(GTP capable node) with a number g inter-frame gap bits 
between said data packets; 

c) cunialyzing said data packet/s in said analyzing 
20 phase, and if said failure is occuring 

d) increasing said g inter- frame gap with G, where G is 
a determined nvimber; 

e) repeating step b-d, and if not said failure occuring 

f) dividing g by two, and if not said failure occuring 
25 g) repeating step b,f until the interframe gap G has 

the value of a previously determinated G for which 
failxire had occured. 

25. A method according to claim 24, 

wherein said determined niamber m is corresponding to 
30 100000, and determined number G is corresponding to 2. 

26. A method according to any one of claims 1-25, 
wherein said sending data packet/s and said processing 
data packet/s comprising the steps of: 
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a) setting a first and second network node (GTP capable 
node) in a cascade; 

b) sending n data packet/s to said first network node 
(GTP capable node) , and analyzing the data packet/s 
returning from said cascaded network nodes (GTP capable 
nodes) in said analyzing phase, and if said failure is 
not occuring; 

c) setting a new network node (GTP capable node) in 
cascade in between said first and second network node 
(GTP capable node) ; 

d) repeating step a-b. 

27. A method according to any one of claims 1-26, 
wherein said, sending data packet/s coirtprising the steps 
of: 

15 a) setting k=l, where k is a data packet number; 

b) setting p=l, where p is a TID number; 

c) sending data packet niomber k, including at least one 
GTP header with TID n-umber p having a number p 
associated APN to said network node (GTP capable node) ; 

20 d) increasing k with one; 

e) increasing p with one; 

f ) if p>P, where P is a determined number, then 

g) repeating step c-f, and if said failure is not 
occuring, then 

25 h) repeating step b-f . 

28. A method according to claim 27, 

wherein said determined number P is corresponding to 
the number of APN associated to said network node (GTP 
capable node) . 

30 29. A method according to any one of claims 1-27, 

wherein said sending data packet/s and said processing 
data packet/s coirtprising the steps of: 

a) setting y=0, where y is a data packet number; 

b) setting k=-l, where k is a sequence nuinber; 
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c) setting n=0, where n is a TID nuinber; 

d) increasing k with one; 

e) increasing n with one; 

f) increasing y with one; 

5 g) sending data packet number y, including at least one 

GTP header with TID nuinber n, and sequence number k, to 
said network node (GTP capable node) ; 

h) if n < N, where N is a determined number, then 

i) repeating step e-h, and if y ^ Y, where Y is a 
10 determined nixmber, then 

j) repeating step c-i. 

30. A method according to any one of claims 1-29, 
wherein said sending data packet /s comprising the steps 
of: 

15 a) setting y=0, where y is data packet number; 

b) setting k=-l, where k is a sequence niamber; 

c) setting n=0, where n is a TID number; 

d) increasing n with one; 

e) increasing k with one; 
20 f ) increasing y with one; 

g) sending data packet number y, including at least one 
GTP header with TID number n, and sequence number k, to 
said network node (GTP capable node) ; 

h) if k S N, where N is a determined niomber, then 

25 i) repeating step e-h, and if y < Y, where Y is a 

determined nxiniber, then 
j) repeating step c-i. 

31, A method according to any one of claims 29 and 30, 
wherein said determined number N is corresponding to 

30 number of PDP context /s activated in said network node 

(GTP capable node) and said determined number Y 
corresponds to total number of data packet /s sent 
during a determined time period or just an estimated 
total n\OTber Y. 
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32. A method according to any one of claims 1-31, 

wherein said sending data packet /s and said processing 
data packet/s coitprising the steps of: 
a) setting value x to 100 and y to 0; 
5 b) sending x% of the total nintiber of the n data packets 

from said testing device to said network node (GTP 
capable node) by Gn interface; 

c) sending y% of the total number of the n data packets 
from said testing device to said network node (GTP 

10 capable node) by interface Gi; 

d) increasing y in steps of u and decreasing x in steps 
of u, where u is a determined number; 

e) repeating steps b-d. 

33. A method according to claim 32, 

15 wherein said determined nuitiber u is corre.sponding to 

20%. 

34. A method according to any one of claims 1-33, 
wherein sending a number n of data packet/s. with 
different frame sizes to said network node (GTP capable 
node) , and 

said frame sizes change in size according to formula: 
min frame size + n*X, wherein 

said X is any niomber of bytes from 1 to max frame size 
to min frame size, and 

n is an integer so that min size + n*X < max frame 
size. 

35. A device for testing the performance of a network node 
(GTP capable node) in a radio communication system, 
characterised in that the device for 

30 testing comprising: 

a means for sending at least one data packet towards at 
least one interface of said network node (GTP capable 
node) and, 
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a means for analyzing the data packet /s returning as a 
response to said sent data packet/s. 

36. A device for testing according to claim 35, 

wherein said testing device is operating according to 
5 the method in claims 1-34. 

37. A data packet for testing the performance of a network 
node (GTP capbable node) in a radio communication 
system, 

characterised in that said data packet for 
10 testing comprising: 

a GTP header with a PDP context activation. 
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